Method and apparatus for providing authentication session sharing

ABSTRACT

An approach is provided for providing authentication session sharing between browsers and run time environments in network communication. An interface receives an authentication context associated with a first service. The interface causes, at least in part, storage of the authentication context in a first cache associated with the interface. The interface causes, at least in part, population of the authentication context to a second cache associated with a second service. The second cache is not directly linked to the interface. The authentication context in the second cache authenticates access to the second service.

BACKGROUND

Network service providers and device manufacturers are continuallychallenged to deliver value, convenience, and security to consumers by,for example, providing compelling network services. It is noted that thenumber and variety of applications provided on user devices iscontinually growing. For example, modern user devices can includeseveral applications (e.g., browsers, client applications, etc.) thatenable a user to access network services provided by differentapplication servers. Convenience and security of access to these serversare important challenges that service providers face every day.Accordingly, in one embodiment, authentication servers can be used toprovide security for such applications to access application servers.Traditionally, authentication information between browser applicationsand different client applications is not shared, therefore, networkresources can be wasted and user experience can be diminished when anauthentication process is repeated for different applications accessedfrom the same device.

SOME EXAMPLE EMBODIMENTS

Therefore, there is a need for an approach for providing authenticationsession sharing between different applications (such as, but not limitedto, browsers and run time environments).

According to one embodiment, a method comprises receiving, at aninterface, an authentication context associated with a first service.The method also comprises causing, at least in part, storage of theauthentication context in a first cache associated with the interface.The method further comprises causing, at least in part, population ofthe authentication context to a second cache. The second cache isassociated with a second service and the second cache is not directlylinked to the interface. The authentication context in the second cacheauthenticates access to the second service.

According to another embodiment, an apparatus comprising at least oneprocessor, and at least one memory including computer program code, theat least one memory and the computer program code configured to, withthe at least one processor, cause, at least in part, the apparatus toreceive an authentication context associated with a first service. Theapparatus is also caused to cause, at least in part, storage of theauthentication context in a first cache associated with the apparatus.The apparatus is further caused to cause, at least in part, populationof the authentication context to a second cache. The second cache isassociated with a second service and the second cache is not directlylinked to the apparatus. The authentication context in the second cacheauthenticates access to the second service.

According to another embodiment, a computer-readable storage mediumcarrying one or more sequences of one or more instructions which, whenexecuted by one or more processors, cause, at least in part, anapparatus to receive an authentication context associated with a firstservice. The apparatus is also caused to cause, at least in part,storage of the authentication context in a first cache associated withthe apparatus. The apparatus is further caused to cause, at least inpart, population of the authentication context to a second cache. Thesecond cache is associated with a second service and the second cache isnot directly linked to the apparatus. The authentication context in thesecond cache authenticates access to the second service.

According to another embodiment, an apparatus comprises means for anauthentication context associated with a first service. The apparatusalso comprises means for causing, at least in part, storage of theauthentication context in a first cache associated with the apparatus.The apparatus further comprises means for causing, at least in part,population of the authentication context to a second cache. The secondcache is associated with a second service and the second cache is notdirectly linked to the apparatus. The authentication context in thesecond cache authenticates access to the second service.

Still other aspects, features, and advantages of the invention arereadily apparent from the following detailed description, simply byillustrating a number of particular embodiments and implementations,including the best mode contemplated for carrying out the invention. Theinvention is also capable of other and different embodiments, and itsseveral details can be modified in various obvious respects, all withoutdeparting from the spirit and scope of the invention. Accordingly, thedrawings and description are to be regarded as illustrative in nature,and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the invention are illustrated by way of example, andnot by way of limitation, in the figures of the accompanying drawings:

FIG. 1 is a diagram of a system capable of providing a platform to shareauthentication session information, according to one embodiment;

FIG. 2 is a diagram of the components of a device enabler, according toone embodiment;

FIG. 3 is a flowchart of a process for sharing authentication sessioninformation, such as authentication context, between differentapplications, according to one embodiment;

FIGS. 4A and 4B are time sequence diagrams that illustrates a sequenceof messages and processes for providing a platform to shareauthentication session information, according to various embodiments;

FIG. 5 is a diagram of an example user interface for providing datarelated to authentication credentials, according to one embodiment;

FIG. 6 is a diagram of hardware that can be used to implement anembodiment of the invention;

FIG. 7 is a diagram of a chip set that can be used to implement anembodiment of the invention; and

FIG. 8 is a diagram of a mobile terminal (e.g., handset) that can beused to implement an embodiment of the invention.

DESCRIPTION OF SOME EMBODIMENTS

Examples of a method, apparatus, and computer program for providingauthentication session sharing between browsers and run timeenvironments are disclosed. In the following description, for thepurposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the embodiments of theinvention. It is apparent, however, to one skilled in the art that theembodiments of the invention may be practiced without these specificdetails or with an equivalent arrangement. In other instances,well-known structures and devices are shown in block diagram form inorder to avoid unnecessarily obscuring the embodiments of the invention.

As used herein, the term network resource refers to any service or datastructure or communication link available through connection to anetwork. A single sign-on (SSO) process refers to any process of asingle provider, which enables a user, during one session connected tothe network, to access a plurality of network resources from thatprovider without redundant entry by the user of user identification orauthentication information. A single provider is often identified by asingle network domain name in the uniform resource identification (URI)naming system, as used for example with a uniform resource locator (URL)naming system. However, it also contemplated that the SSO process canextend to services provided over multiple network domains. An examplesingle sign-on process is the single sign-on processes for the OVI™system of the NOKIA CORPORATION™ of Espoo, Finland. An access provideris a network service provider that grants access for user equipment(e.g., UE 101, described below) to access a network (e.g., communicationnetwork 105, described below).

FIG. 1 is a diagram of a system capable of providing authenticationsession sharing, according to one embodiment. Applications (such as, butnot limited to, applications executing in run-time environments (e.g.,Java runtime, Web runtime, etc.), browsers, etc.) can be executed onuser devices to enable access to services provided by applicationservers. As previously noted, the number and variety of these clientapplications are continually increasing; and security and convenience ofaccess to the application servers through the client applications areimportant challenges facing service providers. Traditionally, for eachclient application (e.g., a browser or client application) to access anapplication server, the client application (and/or a user of the clientapplication) needs to authenticate itself to an authentication server toreceive an authentication context. The authentication context is furtherused by the client application to access the server application.However, this authentication context is not traditionally shared betweendifferent types of client applications. Therefore, each clientapplication type performs its own authentication process to access theapplication servers, for instance, even when accessing the same serversor when the application servers provide related services. This can wastenetwork resources by causing potentially high traffic loads onparticipating application servers and authentication servers, therebydiminishing user experience. For example, an authentication contexthistorically is not shared between an application that runs in a runtime environment and a client application such as browser. Therefore,even if a run time client application has been authenticated and anauthentication context exists, when a user uses a browser to access thesame or related application server (such as a web server), the userand/or the browser performs another authentication process to obtain anauthentication context specific to the browser. This repeatedauthentication can result in potentially high traffic loads onparticipating authentication server.

To address these problems, a system 100 of FIG. 1 can advantageouslyprovide a platform to share authentication session information, such asauthentication context, between different applications such as clientapplications running in run time environments and client applicationssuch as browsers. As used herein, the term “authentication context” caninclude: (1) information regarding initial identification mechanisms ofa user, client, customer, etc.; (2) information regarding authenticationmechanism or method (e.g., passwords, one time password, a cookie, alimited use key, a secret key, a consumer key, an access token, etc.);(3) information regarding storage and protection of credential (e.g.,password rules, smart carts, etc.); and the like.

According to an embodiment of FIG. 1, a user equipment (UE) 101 cancommunicate with multiple network resources, including applicationservers 103 a-130 n (collectively referenced hereinafter as applicationservers 103), through, for example, communication network 105. In oneexample, authentication server 107 can be used to identify,authentication, and/or verify the UE 101, a user of the UE 101, clientapplications, browsers, etc., associated with the UE 101, for access toapplication servers 103. The UE 101 can include an interface, such asdevice enabler (DE) 109, which can provide a platform to shareauthentication session information, such as authentication context,between, for example, client applications 111 a-111 m (collectivelyreferenced hereinafter as client applications 111) and the browser 113.According to an embodiment, when one of the client applications 111 isauthenticated with the authentication server 107 through the DE 109, anauthentication context can be received, for example, at the DE 109 andthe authentication context can then be cached and/or stored at, forexample, a cache and/or an authentication database 117 associated withthe DE 109. The DE 109 can advantageously cause population of theauthentication context from, for example, the cache and/orauthentication database 117 associated with the DE 109 to another cacheand/or database, such as database 115, which is not directly linked tothe DE 109. According to one embodiment, this method can be a pushmethod wherein the authentication context from the authenticationdatabase 117 is transmitted or caused to be transmitted to the database115 without a specific request from the database 115 or applicationassociated with the database 115 (e.g., the browser 113). In thisexample, the browser 113 can use the populated authentication contextfrom the cache and/or database 115 to access the application servers 103without the need for further authentication.

According to certain embodiments, one of the client applications 111,for example, client application 111 a, desires to access the applicationservers 103. An interface, such as the DE module 109, which may beimplemented as a chip set as shown in FIG. 7 and described below, withor without one or more computer program instructions, can receive anauthentication request from the client application 111 a. Theauthentication request can be used to authenticate the clientapplication 111 a, a user of the client application 111 a, or acombination thereof. In one example, the DE 109 determines whether theclient application 111 a, a user of the client application 111 a, or acombination thereof, has already been authenticated to access therequested application server 103 in a current session over thecommunication network 105. If the DE 109 determines that anauthentication is necessary (e.g., if the user has not yet beenauthenticated), a user interface (UI) is generated and a user of theclient application 111 a is prompted for inputs employed to identify andauthenticate the user. In one embodiment, the determination that anauthentication is necessary can be based on lack of an authenticationcontext for the client application 111 a and/or a user of the clientapplication 111 a, an outdated authentication context, etc. In oneexample, the DE 109 can initiate the UI to prompt the user for userauthentication and/or identification inputs. Alternatively oradditionally, the authentication server 107 can initiate the UI.

User input, which can include, but are not limited to, user credentialsis received by the interface DE 109. The user credentials can includeusername, password, biometrics, one time password, network addressfiltering, etc. However, it is contemplated that other authenticationand/or identification schemes can be used. The DE 109 generates anauthentication request for the client application 111 a and/or a user ofthe client application 111 a and conveys the authentication request tothe authentication server 107. The authentication server 107 determinesif the client application 111 a and/or a user of the client application111 a can be authenticated based, at least in part, on the user inputs,such as user credentials. If the authentication fails, theauthentication server 107 informs the DE 109 of the failedauthentication and the DE 109 returns the result of the authenticationto the client application 111 a. However, if the authentication issuccessful (e.g., the user credentials are valid), the authenticationserver 107 generates and returns a valid authentication context to theDE 109. In one example, the success of the authentication is determinedby the authentication server 107 by comparing the received usercredentials with user credentials stored in a database (not shown)associated with the authentication server 107. However, it iscontemplated that other authentication schemes and protocols can be usedto authenticate the client applications 111 and/or user(s) of the clientapplications.

When the DE 109 receives the valid authentication context, in case of asuccessful authentication, the DE 109 informs the client application 111a that the authentication has been successful. Further, the DE 109 cancache and/or store the received authentication context in a cache and/ordatabase, such as authentication database 117 that is associated withthe DE 109. Therefore, if other client applications that are associatedwith the DE 109 (such as client applications 111) request authenticationfrom the DE 109, the existence and validity of the stored authenticationcontext can be checked by the DE 109 and authentication response can besent to the requesting client application without further contacting theauthentication server 107.

Further, the DE 109 can advantageously cause population of theauthentication context cached and/or stored in authentication database117 in another cache and/or database, which is not directly linked withand/or utilizes the DE 109 (such as database 115). In one example, thispopulation of the authentication context provides the platform forsharing authentication session information between applications thatutilize the DE 109 and applications that do not use the DE 109 (such asbrowser 113). Therefore, if the browser 113 desires to access theapplication server 103, the browser 113 can utilize the populatedauthentication context in, for example, the database 115 to authenticateitself (and/or its user) to the application servers 103. By way ofexample, the database 115 can be a cookie store accessible by thebrowser 113. In this way, the browser 113 need not perform an additionalauthentication because the authentication context would already beavailable in the cookie store (e.g., database 115). Moreover, thebrowser 113 (or other similar client application) need not be aware ofthe transfer or population of the authentication context from the DE109. Instead, the browser 113 need only check for the presence of theauthentication context in the cookie store or cache where it normallystores such authentication contexts.

In one example, populating the authentication context between thedatabases 115 and 117 can include copying the authentication contextfrom the authentication database 117 to the database 115. Additionallyor alternatively, populating the authentication context can includeconverting the authentication context received for the clientapplication 111 a to another authentication context based, at least inpart, on an authentication protocol associated with, for example, thebrowser 113 and caching and/or storing the converted authenticationcontext in the cache and/or database 115. In one example, theauthentication context received for the client application 111 a caninclude a token and populating the authentication context in cacheand/or database 115 can include converting the authentication context toan encrypted cookie associated to the browser 113. A cookie (e.g., abrowser cookie or Hypertext Transport Protocol (HTTP) cookie) isgenerally a small piece of text stored on a user device by, forinstance, a web browser or other application. A cookie consists of oneor more name-value pairs containing limited bits of information such asuser preferences, shopping cart contents, an identifier for aserver-based session, or other data used by websites and the applicationservers 103.

In one embodiment, the client applications 111 can include applicationsthat run on run time environments, such as Java Runtime, Web Runtime(WRT), etc. Also, although various embodiments are explained withrespect to browser 113 as a client application that is not directlylinked to the DE 109, it is contemplated that other client applicationsthat do not directly utilize the DE 109 can be used (e.g., other nativeclient applications).

Also, by way of example, the authentication server 107 can include asingle sign-on (SSO) authentication server. Single sign-on is anauthentication process that enables a user (e.g., a user device, aclient application, user of a user device, etc.) to authenticate onceand gain access to resources of multiple software, applications,servers, etc., without being prompted to authenticate itself again ateach of the resources. Therefore, when a client application (such as oneof client applications 111 and/or browser 113) and/or a user of theclient application is authenticated with the authentication server 107,for example, as discussed above, to access one of the applicationservers 103, the client application (and/or the user) can access otherapplication servers (which are supported by the single sign-on scheme)during one session connected to the network, without redundant entry by,for example, the user of the user identification or authenticationinformation. According to this example, the interface DE 109 can beimplemented as an SSO authentication enabler to advantageously shareauthentication session information between different client applications(e.g., client applications 111 and/or browser 113) of the UE 101.

As discussed above, when the interface DE 109 receives an authenticationrequest from one of client applications 111, such as client application111 b, the DE 109 determines whether an authentication process hasalready been performed for the client applications 111. For example, theDE 109 determines whether the authentication context already exists, hasnot expired, or is otherwise valid for authentication other clientapplications 111. If the DE 109 determines that the authenticationprocess has already been performed, the DE 109 informs the clientapplication 111 b of the outcome of the authentication process. Forexample, the DE 109 generates and initiates transmission of a message tothe client application 111 b to inform the client application 111 b of asuccessful or failed authentication attempt. If the DE 109 determinesthat the authentication context exists (and for example, is notoutdated), the authentication context is retrieved from, for example,the cache and/or authentication database 117 and is returned to theclient application 111 b. Therefore, the interface DE 109 implementssingle sign-in functionality by caching and/or storing theauthentication context and retrieving it for requesting clientapplications. The client application 111 b can use the retrievedauthentication context to connect to, for example, the applicationserver 103 a. In one example, the connection request from the clientapplication 111 b to the application server 103 a can include theretrieved authentication context. The application server 103 a canutilize the authentication server 107 to verify the authenticationcontext and allow access by the client application 111 b if theauthentication context is verified. In one embodiment, the verificationof the authentication context can include a verification message (thatfor example includes the authentication context) from the applicationserver 103 a to the authentication server 107, verification of theauthentication context at the authentication server 107 (for example, bycomparing the received authentication context with the storedauthentication contexts), and a verification message from theauthentication server 107 to the application server 103 a indicating theresult of the verification.

In one embodiment, after a client application 111 has been authenticated(e.g., received a valid authentication context), the receivedauthentication context can be cached in, for instance, the database 117which has a direct link to the DE 109. The DE 109 can then populate theauthentication context to the database 115 that is directly accessibleby the browser 113. This population of the authentication context fromthe database 117 to the database 115 advantageously enables the DE 109share an authentication context (e.g., an SSO authentication context)with another application such as the browser 113 that would otherwisehave no direct link to the authentication context via the DE 109. Inthis way, the system 100 also advantageously reduces the use ofcomputing resources, network resources (e.g., bandwidth), powerresources, etc. of the UE 101 and/or the communication network 105 byenabling sharing of an authentication context among different clientapplications 111 for accessing previously authenticated servers (e.g.,the application servers 103).

For example, the browser 113 may desire to access one or more of theapplication servers 103 (e.g., application server 103 a). In thisexample, the browser 113 generates and initiates transmission of anaccess request to the application server 103 a. Since the clientapplications 111 have been authenticated, an authentication context hasbeen received and cached and/or stored, and a populated authenticationcontext exists for the browser 113 in, for example, cache and/ordatabase 115, the access request can include the populatedauthentication context. Therefore, the authentication sessioninformation can be shared between different client applications and nofurther entry of, for example, user credentials for furtherauthentication is necessary. As mentioned, the populated authenticationcontext can be a copy of the authentication context, a converted versionof the authentication context, etc.

By way of example, the application server 103 a that receives the accessrequest, can also generate and initiate transmission of a verificationrequest to verify the received populated authentication context. Theverification request is sent to the authentication server 107. Theauthentication server 107 verifies the validity of the authenticationcontext, for example, by comparison with stored authentication contexts.The authentication server 107 generates and initiates transmission of averification response based, at least in part, on the verification ofthe populated authentication context. If the authentication context isvalid, the access request is granted.

According to certain embodiments, DE 109 can also determine whether anauthentication context is stored or otherwise available in a cacheand/or database (such as database 115) associated with the browser 113.If the authentication is available in the database 115, the DE 109 canretrieve the authentication context to populate the authenticationcontext in the cache and/or database (such as authentication database117) associated with the client applications 111. In one embodiment,this process can be called the pull method for populating theauthentication context to the database 117.

In another example, the browser 113 may desire to access one or more ofthe application servers 103 (for example application server 103 a). Ifthe browser 113, a user of the browser 113, UE 101, a user of UE 101, ora combination thereof has not already been authenticated to access theapplication server 103 a (e.g., no valid authentication context isstored in the database 115 associated with the browser 113), the browser113 can be directed to the authentication server 107 for authentication.In one embodiment, the browser 113 receives a request for usercredentials, for example, from the authentication server 107 and, inresponse, sends the user credentials to the authentication server 107.In this example, the authentication server 107 can determine thevalidity of user credentials by, for example, a comparison of thepresented credentials against stored credentials. It is contemplatedthat any other authentication mechanism can be implemented to ensurethat only authorized users are able to access the application servers103. If the browser 113, a user of the browser 113, UE 101, a user of UE101, or a combination thereof is authenticated, the authenticationserver 107 can generate and transmit an authentication context to thebrowser 113. The browser 113 can then store the received authenticationcontext in the database 115 of the browser 113. Further access requeststo application servers 103 by the browser 113 can be authenticated usingthe cached authentication context.

In certain embodiments, DE 109 can also populate the authenticationcontext stored in the database 115 that is directly accessible by thebrowser 113 to a cache and/or database (e.g., database 117) that isassociated with the client applications 111. In one embodiment, DE 109can determine that an authentication context associated to the browser113 is available and can populate the authentication context to theauthentication database 117 to be used by client applications 111. Morespecifically, the authentication of the browser 113, a user of thebrowser 113, UE 101, a user of UE 101, or a combination thereof can bethrough the DE 109, therefore, the DE 109 can determine existence of theauthentication context for the browser 113. This population of theauthentication context from the database 115 to the database 117advantageously enables the DE 109 share an authentication context (e.g.,an SSO authentication context) with other applications such as theclient applications 111 that would otherwise have no direct link to thedatabase 115.

As discussed, in one example, populating the authentication contextbetween the databases 115 and 117 can include copying the authenticationcontext from the authentication database 115 to the database 117.Additionally or alternatively, populating the authentication context caninclude converting the authentication context received for the browser113 to another authentication context based, at least in part, on anauthentication protocol associated with, for example, the clientapplications 111 and caching and/or storing the converted authenticationcontext in the authentication cache and/or database 117. In oneembodiment, the authentication context that was generated for thebrowser 113 can be a cookie-based authentication context (for example,but not limited to, an encrypted cookie). In one example, populating theauthentication context from database 115 to authentication database 117can include converting the cookie-based authentication context to atoken-based authentication context.

As discussed previously, implementing a platform to share authenticationcontext between, for example, client applications 111 and the browser113 can advantageously reduce communication load on the authenticationserver 107 by reducing number of authentication requests generated bythe client applications 111 and the browser 113 that is destined for theauthentication server 107.

By way of example, the communication network 105 of system 100 includesone or more networks such as a data network (not shown), a wirelessnetwork (not shown), a telephony network (not shown), or any combinationthereof. It is contemplated that the data network may be any local areanetwork (LAN), metropolitan area network (MAN), wide area network (WAN),a public data network (e.g., the Internet), short range wirelessnetwork, or any other suitable packet-switched network, such as acommercially owned, proprietary packet-switched network, e.g., aproprietary cable or fiber-optic network, and the like, or anycombination thereof. In addition, the wireless network may be, forexample, a cellular network and may employ various technologiesincluding enhanced data rates for global evolution (EDGE), generalpacket radio service (GPRS), global system for mobile communications(GSM), Internet protocol multimedia subsystem (IMS), universal mobiletelecommunications system (UMTS), etc., as well as any other suitablewireless medium, e.g., worldwide interoperability for microwave access(WiMAX), Long Term Evolution (LTE) networks, code division multipleaccess (CDMA), wideband code division multiple access (WCDMA), wirelessfidelity (WiFi), wireless LAN (WLAN), Bluetooth®, Internet Protocol (IP)data casting, satellite, mobile ad-hoc network (MANET), and the like, orany combination thereof.

The UE 101 is any type of mobile terminal, fixed terminal, or portableterminal including a mobile handset, station, unit, device, multimediacomputer, multimedia tablet, Internet node, communicator, desktopcomputer, laptop computer, Personal Digital Assistants (PDAs),audio/video player, digital camera/camcorder, positioning device,television receiver, radio broadcast receiver, electronic book device,game device, or any combination thereof. It is also contemplated thatthe UE 101 can support any type of interface to the user (such as“wearable” circuitry, etc.).

By way of example, the UE 101, the application servers 103 a-103 n, andthe authentication server 107, communicate with each other and othercomponents of the communication network 105 using well known, new orstill developing protocols. In this context, a protocol includes a setof rules defining how the network nodes within the communication network105 interact with each other based on information sent over thecommunication links. The protocols are effective at different layers ofoperation within each node, from generating and receiving physicalsignals of various types, to selecting a link for transferring thosesignals, to the format of information indicated by those signals, toidentifying which software application executing on a computer systemsends or receives the information. The conceptually different layers ofprotocols for exchanging information over a network are described in theOpen Systems Interconnection (OSI) Reference Model.

Communications between the network nodes are typically effected byexchanging discrete packets of data. Each packet typically comprises (1)header information associated with a particular protocol, and (2)payload information that follows the header information and containsinformation that may be processed independently of that particularprotocol. In some protocols, the packet includes (3) trailer informationfollowing the payload and indicating the end of the payload information.The header includes information such as the source of the packet, itsdestination, the length of the payload, and other properties used by theprotocol. Often, the data in the payload for the particular protocolincludes a header and payload for a different protocol associated with adifferent, higher layer of the OSI Reference Model. The header for aparticular protocol typically indicates a type for the next protocolcontained in its payload. The higher layer protocol is said to beencapsulated in the lower layer protocol. The headers included in apacket traversing multiple heterogeneous networks, such as the Internet,typically include a physical (layer 1) header, a data-link (layer 2)header, an internetwork (layer 3) header and a transport (layer 4)header, and various application headers (layer 5, layer 6 and layer 7)as defined by the OSI Reference Model.

It is noted that although FIG. 1 illustrates the application servers 103and the authentication server 107 as separate entities, it iscontemplated that any combination of these servers can be implementedsuch that the functions of these components may be combined in one ormore components or performed by other components of equivalentfunctionality. Also, it is contemplated that the client applications111, browser 113, and DE 109 can be distributed on different devicesand/or equipment and the authentication context can be shared using acommunication network.

In one embodiment, the client applications 111 and the browser 113interact with the application servers 103 according to a client-servermodel. It is noted that the client-server model of computer processinteraction is widely known and used. According to the client-servermodel, a client process sends a message including a request to a serverprocess, and the server process responds by providing a service. Theserver process may also return a message with a response to the clientprocess. Often the client process and server process execute ondifferent computer devices, called hosts, and communicate via a networkusing one or more protocols for network communications. The term“server” is conventionally used to refer to the process that providesthe service, or the host computer on which the process operates.Similarly, the term “client” is conventionally used to refer to theprocess that makes the request, or the host computer on which theprocess operates. As used herein, the terms “client” and “server” referto the processes, rather than the host computers, unless otherwise clearfrom the context. In addition, the process performed by a server can bebroken up to run as multiple processes on multiple hosts (sometimescalled tiers) for reasons that include reliability, scalability, andredundancy, among others.

FIG. 2 is a diagram of the components of a device enabler, according toone embodiment. By way of example, the device enabler (DE) 109 caninclude one or more components for providing a platform to shareauthentication session information, such as authentication context,between different applications such as client applications running onrun time environments and client applications such as browsers. It iscontemplated that the functions of these components may be combined inone or more components or performed by other components of equivalentfunctionality. In this embodiment, the DE 109 can include a processor201 or other logic for executing at least one algorithm for performingthe functions of the DE 109. For example, when the DE 109 is accessed byone of the client applications 111 of FIG. 1 for authentication, theprocessor 201 in communication with the retrieval module 203, determineswhether an authentication procedure has already been processed for theclient application (and/or related client applications). For example,the retrieval module 203 can determine whether an authentication contextexists for the client application requesting authentication. In oneexample, the retrieval module 203 can query the authentication database117 to determine if the authentication context is available.Additionally, the retrieval module 203 can further determine if theauthentication context is still valid, for example, if it has notexpired.

If the processor 201 in communication with the retrieval module 203determines that a valid authentication context is available for therequesting client application, the retrieval module 203 retrieves theauthentication context from a cache and/or a database such as theauthentication database 117 and initiates transmission of theauthentication context to the client application 111 requestingauthentication. However, if the retrieval module 203 determines that anauthentication procedure has already been processed by the DE 109 forthe client application, which resulted in a failed authentication, thefailed authentication result is further provided to the clientapplication.

Alternatively, according to certain embodiments, if the retrieval module203 determines that no valid authentication context exists for theclient application that requested authentication, user interface module205 is invoked to launch a user interface (UI) to prompt a user of theclient application 111 to provide authentication and/or identificationinformation, such as user credentials. Data collection module 207 cancollect the user authentication information and prepare anauthentication request message to be sent to an authentication server,such as authentication server 107 of FIG. 1. The authentication server107 can verify the user authentication information and generate anauthentication context if the user and/or the client application isauthorized or otherwise validated. In one example, the user informationcan include user credentials such as username and password and theauthentication server 107 can compare the user credentials with storedcredentials to authenticate the user and/or client application. Datacollection module 207 can receive the authentication context from theauthentication server 107. Further, the data collection module 207 canreceive a failed authentication message from the authentication server107 if the user information is not valid. The result of theauthentication request (authentication context or failed authenticationmessage) is conveyed to the client application.

According to certain embodiments, if the authentication is successfuland the authentication context is received by, for example, the datacollection module 207, the caching/storage/population module 209 cancache and/or store the authentication context in, for example, theauthentication database 117. Therefore, the authentication context canbe used by, for example, the retrieval module 203 for authenticatingsubsequent requests from the same and/or other client applicationsassociated with the DE 109. Further, the caching/storage/populationmodule 209 can advantageously initiate population of the authenticationcontext in another cache and/or database that is not directly linkedwith and/or utilizes the DE 109. For example, thecaching/storage/population module 209 can populate the receivedauthentication context in database 115 of FIG. 1 associated with thebrowser 113 of FIG. 1. Therefore, browser 113 of FIG. 1 can use thepopulated authentication context to access application servers 103 ofFIG. 1 without a need to first authenticate itself with theauthentication server 107. As mentioned, the caching/storage/populationmodule 209 can populate the authentication context by copying it,converting it based, at least in part, on an authentication schemesupported by, for example, browser 113 of FIG. 1, etc.

FIG. 3 is a flowchart of a process for sharing authentication sessioninformation, such as authentication context, between differentapplications (such as client applications running on run timeenvironments and client applications such as browsers), according to oneembodiment. In one embodiment, the device enabler (DE) 109 of FIG. 1performs the process 300 and is implemented in, for instance, a chip setincluding a processor and a memory as shown in FIG. 7.

In step 301, an authentication request is received. In one embodiment,the authentication request is received from a client application (suchas client applications 111 a-111 m of FIG. 1) that is directly linkedwith and/or utilizes the DE 109. The authentication request can includeinformation associated with the client application, a user of the clientapplication, etc. In step 303, a determination is made regarding whetheran authentication context already exists for the client applicationrequesting authentication. In one example, the determination can bebased on generating a query to a database, such as authenticationdatabase 117, to determine whether an authentication context associatedwith the client application was previously received and stored in thedatabase 117. Additionally, according to certain embodiments, if theauthentication context exists, in step 303 a determination can be madewhether the authentication is valid, for example, if it has not expired.If a (valid) authentication context is available, in step 305 theauthentication context is retrieved from, for example, a cache and/or adatabase, such as the authentication database 117 of FIG. 1. In step307, the retrieved authentication context is transmitted to the clientapplication requesting authentication. The client application can usethe authentication context to access network services such asapplication servers 103 of FIG. 1.

However, if in step 303 it is determined that a valid authenticationcontext is not available, a request to receive authenticationcredentials associated with a user of the client application, whichrequests authentication, is generated in step 309. In one example, auser interface is initiated to prompt the user for authenticationcredentials, such as username, password, one time password, biometrics,etc. In step 311, the authentication credentials are received from theclient application based, at least in part, on the request.

In step 313, an authentication message is generated based, at least inpart, on the received authentication credentials and the authenticationmessage is transmitted to an authentication server, such asauthentication server 107 of FIG. 1. The authentication server validatesthe authentication credentials (for example, by comparing it to storedcredentials) to determine whether the user and/or the client applicationis authorized. In step 315, the result of the user and/or clientauthentication is received. More specifically, if the user and/or theclient application are authorized, in step 315, an authenticationcontext is received. In step 317, the authentication context is cachedand/or stored in a cache and/or a database associated with the DE 109such as the authentication database 117 of FIG. 1. The cached and/orstored authentication context can be further used by other clientapplications, which, for example, are directly linked with and/orutilize the DE 109.

In step 319, the authentication context is further populated in a secondcache and/or database, which is not directly linked with and/or utilizesthe DE 109, for example, the database 115 of FIG. 1. In one example, thedatabase 115 can be a cookie store associated with the browser 113 ofFIG. 1. As mentioned, in one embodiment, in step 319, the population ofthe authentication context can include converting the authenticationcontext based, at least in part, on an authentication scheme associatedwith the client application associated with the second cache and/ordatabase. For example, the authentication context can include a tokenand in step 319 the authentication context is converted to a convertedauthentication context that include a cookie encrypted using usernameand password of the user.

FIGS. 4A and 4B are time sequence diagrams that illustrate a sequence ofmessages and processes for providing a platform to share authenticationsession information, according to various embodiments. A network processis represented by vertical line. A message passed from one process toanother is represented by horizontal arrows. A step performed by aprocess is indicated by the text. The processes represented in FIGS. 4Aand 4B are the application servers 103, the authentication server 107,the device enabler (DE) 109, the client applications 111, the browser113, the database 115, and the authentication database 117. The exampleof FIG. 4A discusses the process 400 of authenticating a clientapplication and/or a user of the client application, receivingauthentication context, storing the authentication context in a firstcache and/or database, and populating the authentication context in asecond cache and/or database. Also, the example of FIG. 4B discusses theprocess 420 of requesting authentication by a client application andaccessing an application server by the browser.

At 401 of process 400, one of the client applications 111 of FIG. 1,such as client application 111 a initiates an authentication request tothe device enabler (DE) 109. In one example, the authentication requestcan include information associated to the client application 111 a, auser of the client application, an application server that the clientapplication 111 a desires to access, etc. At 403, the device enabler 109initiates a dialog, such as a user interface (UI), to prompt the userfor authentication credentials, if the DE 109 determines that the clientapplication 111 a has not already been authenticated. In one example,the determination is based, at least in part, on a search on a cacheand/or a database associated with the DE 109 (such as the authenticationdatabase 117) to determine whether an authentication context associatedwith the client application 111 a exists. During the dialog 403, the DE109 can collect authentication credentials of, for example, a user ofthe client application 111 a (and/or a user of the UE 101).

At 405, the DE 109 generates and transmits an authentication request tothe authentication server 107 to validate the authentication credentialscollected by the DE 109. In one example, the authentication request caninclude the authentication credentials and/or information associated tothe credentials. By way of example, the credentials can includeusername, password, one time password, consumer key, secret key,biometrics, etc. At 407, the authentication server 107 verifies theauthentication credentials to determine whether the client applicationand/or the user are authorized. In one example, the receivedauthentication credentials (or information associated to them) arecompared with stored credentials. If authorized, at 409, anauthentication context is conveyed to the DE 109. According to oneembodiment, the authentication context can include a cookie or a token.

The DE 109, at 411, initiates caching and/or storage of theauthentication context in a cache and/or a database that is directlylinked to and/or utilizes the DE 109, such as authentication database117. The cached/stored authentication context can be further used byclient applications directly linked to and/or utilizing theauthentication database 117 and/or DE 109. At 413, the DE 109 conveysthe authentication context received from the authentication server 107to the client application 111 a that requested authentication. Further,at 415 the authentication context is populated at a cache and/or adatabase that is not directly linked with and/or utilizes the DE 109. Inone example, the authentication context is populated from theauthentication database 117 to database 115. As mentioned, according tocertain embodiments, at 415, the authentication context is convertedbased, at least in part, on an authentication protocol associated withthe client application (such as the browser 113) that utilizes thedatabase 115. It is contemplated that the messages and/or processesillustrated can be combined in one or more messages and/or processes orperformed in other sequences.

FIG. 4B illustrates exemplary processes of a client application (such asclient application 111 b) requesting authentication and a browserrequesting access to an application server. At 421, the clientapplication 111 b sends an authentication request to the DE 109. In oneexample, the authentication request can include information associatedwith the client application 111 b, a user of the client application 111b, etc. At 423, the authentication context associated with the clientapplication 111 b is retrieved and at 425 the retrieved authenticationcontext is conveyed to the client application 425. According to certainembodiments, at 423, the DE 109 determines whether an authenticationprocess has already been performed for the client application 111 band/or client applications (such as client applications 111) related tothe client application 111 b. In one example, the determination can bebased, at least in part, on a query to the authentication database 117of FIG. 1 to determine whether a valid authentication context isavailable. If no valid authentication context is available, process 400of FIG. 4A can be performed. If the valid authentication context isavailable, it is retrieved and is conveyed to the client application 111b. The client application 111 b can use the authentication context to,for example, access application servers 103 of FIG. 1.

FIG. 4B further illustrates steps 427 through 435 which describe anexemplary process of the browser 113 accessing the application server103 using authentication context populated at 415 of FIG. 4A. At 427,the browser 113 sends a data request to the application server 103. Thedata request can include information related to the browser 113, theapplication server 103, the populated authentication context, etc. In anembodiment, the authentication context has been populated in, forexample, a cache and/or database associated with the browser 113 in aprocess such as process 400 of FIG. 4A. In one example, the populatedauthentication context can be a cookie that is stored in a browsercookie store. The browser 113 can access the browser cookie store toretrieve the cookie and include it in the data request 427.

At 429 through 433, the application server 103 with the authenticationserver 107 verifies the validity of the populated authenticationcontext. At 429, the application server 103 generates an authenticationverification message and conveys the message to the authenticationserver 107. The authentication verification message can include thepopulated authentication context and/or information associated with it.At 431, the authentication server 107 verifies if the populatedauthentication context is valid. In one example, the authenticationcontext 431 compares the authentication context (and/or informationassociated with it) to the authentication context (informationassociated with it, and/or authentication credentials of a user orclient application) that was generated, for example at 407 of process400 of FIG. 4A. At 433, the authentication server 107 sends averification response to the application server 103 based, at least inpart, on 431. If the populated authentication context is valid, at 435,the application server 103 returns the requested data to the browser113.

Although the embodiments discussed are concerned with processes thatauthentication context is first generated for client applicationsrunning on run time environment and is populated for other applications,such as browsers (e.g., via a push method for sharing authenticationcontexts), however it is contemplated reverse process (e.g., via a pullmethod for sharing authentication contexts) can also be implemented. Forexample, a client application, such as a browser, can be authenticatedagainst an authentication server (such as authentication server 107 ofFIG. 1), an authentication context can be generated and be cached and/orstored in a first cache and/or database associated with the clientapplication, and the authentication context can be further populated ina second cache and/or database for other client applications that arenot directly linked with and/or utilize the first cache and/or database.

FIG. 5 is a diagram of an example user interface for providing datarelated to authentication credentials, according to one embodiment. Asdescribed previously, when the DE 109 of FIG. 1 receives anauthentication request from one of the client applications 111 anddetermines that valid authentication context is not available, the DEcan initiate a user interface (UI) to prompt a user of the clientapplication for authentication credentials. FIG. 5 is a sample userinterface 500 requesting such information. In this example, the userand/or the UE 101 can enter the user ID and password for authenticationpurposes. It is contemplated that the DE 109 may request any informationfor ensuring that only authorized users are able to access the requestedservices and/or information.

The processes described herein for providing a platform to shareauthentication session information, such as authentication context,between different applications may be advantageously implemented viasoftware, hardware (e.g., general processor, Digital Signal Processing(DSP) chip, an Application Specific Integrated Circuit (ASIC), FieldProgrammable Gate Arrays (FPGAs), etc.), firmware or a combinationthereof. Such exemplary hardware for performing the described functionsis detailed below.

FIG. 6 illustrates a computer system 600 upon which an embodiment of theinvention may be implemented. Although computer system 600 is depictedwith respect to a particular device or equipment, it is contemplatedthat other devices or equipment (e.g., network elements, servers, etc.)within FIG. 6 can deploy the illustrated hardware and components ofsystem 600. Computer system 600 is programmed (e.g., via computerprogram code or instructions) to provide authentication session sharingas described herein and includes a communication mechanism such as a bus610 for passing information between other internal and externalcomponents of the computer system 600. Information (also called data) isrepresented as a physical expression of a measurable phenomenon,typically electric voltages, but including, in other embodiments, suchphenomena as magnetic, electromagnetic, pressure, chemical, biological,molecular, atomic, sub-atomic and quantum interactions. For example,north and south magnetic fields, or a zero and non-zero electricvoltage, represent two states (0, 1) of a binary digit (bit). Otherphenomena can represent digits of a higher base. A superposition ofmultiple simultaneous quantum states before measurement represents aquantum bit (qubit). A sequence of one or more digits constitutesdigital data that is used to represent a number or code for a character.In some embodiments, information called analog data is represented by anear continuum of measurable values within a particular range. Computersystem 600, or a portion thereof, constitutes a means for performing oneor more steps of providing authentication session sharing.

A bus 610 includes one or more parallel conductors of information sothat information is transferred quickly among devices coupled to the bus610. One or more processors 602 for processing information are coupledwith the bus 610.

A processor 602 performs a set of operations on information as specifiedby computer program code related to providing authentication sessionsharing. The computer program code is a set of instructions orstatements providing instructions for the operation of the processorand/or the computer system to perform specified functions. The code, forexample, may be written in a computer programming language that iscompiled into a native instruction set of the processor. The code mayalso be written directly using the native instruction set (e.g., machinelanguage). The set of operations include bringing information in fromthe bus 610 and placing information on the bus 610. The set ofoperations also typically include comparing two or more units ofinformation, shifting positions of units of information, and combiningtwo or more units of information, such as by addition or multiplicationor logical operations like OR, exclusive OR (XOR), and AND. Eachoperation of the set of operations that can be performed by theprocessor is represented to the processor by information calledinstructions, such as an operation code of one or more digits. Asequence of operations to be executed by the processor 602, such as asequence of operation codes, constitute processor instructions, alsocalled computer system instructions or, simply, computer instructions.Processors may be implemented as mechanical, electrical, magnetic,optical, chemical or quantum components, among others, alone or incombination.

Computer system 600 also includes a memory 604 coupled to bus 610. Thememory 604, such as a random access memory (RAM) or other dynamicstorage device, stores information including processor instructions forproviding authentication session sharing. Dynamic memory allowsinformation stored therein to be changed by the computer system 600. RAMallows a unit of information stored at a location called a memoryaddress to be stored and retrieved independently of information atneighboring addresses. The memory 604 is also used by the processor 602to store temporary values during execution of processor instructions.The computer system 600 also includes a read only memory (ROM) 606 orother static storage device coupled to the bus 610 for storing staticinformation, including instructions, that is not changed by the computersystem 600. Some memory is composed of volatile storage that loses theinformation stored thereon when power is lost. Also coupled to bus 610is a non-volatile (persistent) storage device 608, such as a magneticdisk, optical disk or flash card, for storing information, includinginstructions, that persists even when the computer system 600 is turnedoff or otherwise loses power.

Information, including instructions for providing authentication sessionsharing, is provided to the bus 610 for use by the processor from anexternal input device 612, such as a keyboard containing alphanumerickeys operated by a human user, or a sensor. A sensor detects conditionsin its vicinity and transforms those detections into physical expressioncompatible with the measurable phenomenon used to represent informationin computer system 600. Other external devices coupled to bus 610, usedprimarily for interacting with humans, include a display device 614,such as a cathode ray tube (CRT) or a liquid crystal display (LCD), orplasma screen or printer for presenting text or images, and a pointingdevice 616, such as a mouse or a trackball or cursor direction keys, ormotion sensor, for controlling a position of a small cursor imagepresented on the display 614 and issuing commands associated withgraphical elements presented on the display 614. In some embodiments,for example, in embodiments in which the computer system 600 performsall functions automatically without human input, one or more of externalinput device 612, display device 614 and pointing device 616 is omitted.

In the illustrated embodiment, special purpose hardware, such as anapplication specific integrated circuit (ASIC) 620, is coupled to bus610. The special purpose hardware is configured to perform operationsnot performed by processor 602 quickly enough for special purposes.Examples of application specific ICs include graphics accelerator cardsfor generating images for display 614, cryptographic boards forencrypting and decrypting messages sent over a network, speechrecognition, and interfaces to special external devices, such as roboticarms and medical scanning equipment that repeatedly perform some complexsequence of operations that are more efficiently implemented inhardware.

Computer system 600 also includes one or more instances of acommunications interface 670 coupled to bus 610. Communication interface670 provides a one-way or two-way communication coupling to a variety ofexternal devices that operate with their own processors, such asprinters, scanners and external disks. In general the coupling is with anetwork link 678 that is connected to a local network 680 to which avariety of external devices with their own processors are connected. Forexample, communication interface 670 may be a parallel port or a serialport or a universal serial bus (USB) port on a personal computer. Insome embodiments, communications interface 670 is an integrated servicesdigital network (ISDN) card or a digital subscriber line (DSL) card or atelephone modem that provides an information communication connection toa corresponding type of telephone line. In some embodiments, acommunication interface 670 is a cable modem that converts signals onbus 610 into signals for a communication connection over a coaxial cableor into optical signals for a communication connection over a fiberoptic cable. As another example, communications interface 670 may be alocal area network (LAN) card to provide a data communication connectionto a compatible LAN, such as Ethernet. Wireless links may also beimplemented. For wireless links, the communications interface 670 sendsor receives or both sends and receives electrical, acoustic orelectromagnetic signals, including infrared and optical signals, thatcarry information streams, such as digital data. For example, inwireless handheld devices, such as mobile telephones like cell phones,the communications interface 670 includes a radio band electromagnetictransmitter and receiver called a radio transceiver. In certainembodiments, the communications interface 670 enables connection to thecommunication network 105 for providing authentication session sharingto the UE 101.

The term “computer-readable medium” as used herein to refer to anymedium that participates in providing information to processor 602,including instructions for execution. Such a medium may take many forms,including, but not limited to computer-readable storage medium (e.g.,non-volatile media, volatile media), and transmission media.Non-transitory media, such as non-volatile media, include, for example,optical or magnetic disks, such as storage device 608. Volatile mediainclude, for example, dynamic memory 604. Transmission media include,for example, coaxial cables, copper wire, fiber optic cables, andcarrier waves that travel through space without wires or cables, such asacoustic waves and electromagnetic waves, including radio, optical andinfrared waves. Signals include man-made transient variations inamplitude, frequency, phase, polarization or other physical propertiestransmitted through the transmission media. Common forms ofcomputer-readable media include, for example, a floppy disk, a flexibledisk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM,CDRW, DVD, any other optical medium, punch cards, paper tape, opticalmark sheets, any other physical medium with patterns of holes or otheroptically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM,any other memory chip or cartridge, a carrier wave, or any other mediumfrom which a computer can read. The term computer-readable storagemedium is used herein to refer to any computer-readable medium excepttransmission media.

Logic encoded in one or more tangible media includes one or both ofprocessor instructions on a computer-readable storage media and specialpurpose hardware, such as ASIC 620.

Network link 678 typically provides information communication usingtransmission media through one or more networks to other devices thatuse or process the information. For example, network link 678 mayprovide a connection through local network 680 to a host computer 682 orto equipment 684 operated by an Internet Service Provider (ISP). ISPequipment 684 in turn provides data communication services through thepublic, world-wide packet-switching communication network of networksnow commonly referred to as the Internet 690.

A computer called a server host 692 connected to the Internet hosts aprocess that provides a service in response to information received overthe Internet. For example, server host 692 hosts a process that providesinformation representing video data for presentation at display 614. Itis contemplated that the components of system 600 can be deployed invarious configurations within other computer systems, e.g., host 682 andserver 692.

At least some embodiments of the invention are related to the use ofcomputer system 600 for implementing some or all of the techniquesdescribed herein. According to one embodiment of the invention, thosetechniques are performed by computer system 600 in response to processor602 executing one or more sequences of one or more processorinstructions contained in memory 604. Such instructions, also calledcomputer instructions, software and program code, may be read intomemory 604 from another computer-readable medium such as storage device608 or network link 678. Execution of the sequences of instructionscontained in memory 604 causes processor 602 to perform one or more ofthe method steps described herein. In alternative embodiments, hardware,such as ASIC 620, may be used in place of or in combination withsoftware to implement the invention. Thus, embodiments of the inventionare not limited to any specific combination of hardware and software,unless otherwise explicitly stated herein.

The signals transmitted over network link 678 and other networks throughcommunications interface 670, carry information to and from computersystem 600. Computer system 600 can send and receive information,including program code, through the networks 680, 690 among others,through network link 678 and communications interface 670. In an exampleusing the Internet 690, a server host 692 transmits program code for aparticular application, requested by a message sent from computer 600,through Internet 690, ISP equipment 684, local network 680 andcommunications interface 670. The received code may be executed byprocessor 602 as it is received, or may be stored in memory 604 or instorage device 608 or other non-volatile storage for later execution, orboth. In this manner, computer system 600 may obtain application programcode in the form of signals on a carrier wave.

Various forms of computer readable media may be involved in carrying oneor more sequence of instructions or data or both to processor 602 forexecution. For example, instructions and data may initially be carriedon a magnetic disk of a remote computer such as host 682. The remotecomputer loads the instructions and data into its dynamic memory andsends the instructions and data over a telephone line using a modem. Amodem local to the computer system 600 receives the instructions anddata on a telephone line and uses an infra-red transmitter to convertthe instructions and data to a signal on an infra-red carrier waveserving as the network link 678. An infrared detector serving ascommunications interface 670 receives the instructions and data carriedin the infrared signal and places information representing theinstructions and data onto bus 610. Bus 610 carries the information tomemory 604 from which processor 602 retrieves and executes theinstructions using some of the data sent with the instructions. Theinstructions and data received in memory 604 may optionally be stored onstorage device 608, either before or after execution by the processor602.

FIG. 7 illustrates a chip set 700 upon which an embodiment of theinvention may be implemented. Chip set 700 is programmed to provideauthentication session sharing as described herein and includes, forinstance, the processor and memory components described with respect toFIG. 6 incorporated in one or more physical packages (e.g., chips). Byway of example, a physical package includes an arrangement of one ormore materials, components, and/or wires on a structural assembly (e.g.,a baseboard) to provide one or more characteristics such as physicalstrength, conservation of size, and/or limitation of electricalinteraction. It is contemplated that in certain embodiments the chip setcan be implemented in a single chip. Chip set 700, or a portion thereof,constitutes a means for performing one or more steps of providingauthentication session sharing.

In one embodiment, the chip set 700 includes a communication mechanismsuch as a bus 701 for passing information among the components of thechip set 700. A processor 703 has connectivity to the bus 701 to executeinstructions and process information stored in, for example, a memory705. The processor 703 may include one or more processing cores witheach core configured to perform independently. A multi-core processorenables multiprocessing within a single physical package. Examples of amulti-core processor include two, four, eight, or greater numbers ofprocessing cores. Alternatively or in addition, the processor 703 mayinclude one or more microprocessors configured in tandem via the bus 701to enable independent execution of instructions, pipelining, andmultithreading. The processor 703 may also be accompanied with one ormore specialized components to perform certain processing functions andtasks such as one or more digital signal processors (DSP) 707, or one ormore application-specific integrated circuits (ASIC) 709. A DSP 707typically is configured to process real-world signals (e.g., sound) inreal time independently of the processor 703. Similarly, an ASIC 709 canbe configured to performed specialized functions not easily performed bya general purposed processor. Other specialized components to aid inperforming the inventive functions described herein include one or morefield programmable gate arrays (FPGA) (not shown), one or morecontrollers (not shown), or one or more other special-purpose computerchips.

The processor 703 and accompanying components have connectivity to thememory 705 via the bus 701. The memory 705 includes both dynamic memory(e.g., RAM, magnetic disk, writable optical disk, etc.) and staticmemory (e.g., ROM, CD-ROM, etc.) for storing executable instructionsthat when executed perform the inventive steps described herein toprovide authentication session sharing. The memory 705 also stores thedata associated with or generated by the execution of the inventivesteps.

FIG. 8 is a diagram of exemplary components of a mobile terminal (e.g.,handset) for communications, which is capable of operating in the systemof FIG. 1, according to one embodiment. In some embodiments, mobileterminal 800, or a portion thereof, constitutes a means for performingone or more steps of providing authentication session sharing.Generally, a radio receiver is often defined in terms of front-end andback-end characteristics. The front-end of the receiver encompasses allof the Radio Frequency (RF) circuitry whereas the back-end encompassesall of the base-band processing circuitry. As used in this application,the term “circuitry” refers to both: (1) hardware-only implementations(such as implementations in only analog and/or digital circuitry), and(2) to combinations of circuitry and software (and/or firmware) (suchas, if applicable to the particular context, to a combination ofprocessor(s), including digital signal processor(s), software, andmemory(ies) that work together to cause an apparatus, such as a mobilephone or server, to perform various functions). This definition of“circuitry” applies to all uses of this term in this application,including in any claims. As a further example, as used in thisapplication and if applicable to the particular context, the term“circuitry” would also cover an implementation of merely a processor (ormultiple processors) and its (or their) accompanying software/orfirmware. The term “circuitry” would also cover if applicable to theparticular context, for example, a baseband integrated circuit orapplications processor integrated circuit in a mobile phone or a similarintegrated circuit in a cellular network device or other networkdevices.

Pertinent internal components of the telephone include a Main ControlUnit (MCU) 803, a Digital Signal Processor (DSP) 805, and areceiver/transmitter unit including a microphone gain control unit and aspeaker gain control unit. A main display unit 807 provides a display tothe user in support of various applications and mobile terminalfunctions that perform or support the steps of providing authenticationsession sharing. The display 807 includes display circuitry configuredto display at least a portion of a user interface of the mobile terminal(e.g., mobile telephone). Additionally, the display 807 and displaycircuitry are configured to facilitate user control of at least somefunctions of the mobile terminal. An audio function circuitry 809includes a microphone 811 and microphone amplifier that amplifies thespeech signal output from the microphone 811. The amplified speechsignal output from the microphone 811 is fed to a coder/decoder (CODEC)813.

A radio section 815 amplifies power and converts frequency in order tocommunicate with a base station, which is included in a mobilecommunication system, via antenna 817. The power amplifier (PA) 819 andthe transmitter/modulation circuitry are operationally responsive to theMCU 803, with an output from the PA 819 coupled to the duplexer 821 orcirculator or antenna switch, as known in the art. The PA 819 alsocouples to a battery interface and power control unit 820.

In use, a user of mobile terminal 801 speaks into the microphone 811 andhis or her voice along with any detected background noise is convertedinto an analog voltage. The analog voltage is then converted into adigital signal through the Analog to Digital Converter (ADC) 823. Thecontrol unit 803 routes the digital signal into the DSP 805 forprocessing therein, such as speech encoding, channel encoding,encrypting, and interleaving. In one embodiment, the processed voicesignals are encoded, by units not separately shown, using a cellulartransmission protocol such as global evolution (EDGE), general packetradio service (GPRS), global system for mobile communications (GSM),Internet protocol multimedia subsystem (IMS), universal mobiletelecommunications system (UMTS), etc., as well as any other suitablewireless medium, e.g., microwave access (WiMAX), Long Term Evolution(LTE) networks, code division multiple access (CDMA), wideband codedivision multiple access (WCDMA), wireless fidelity (WiFi), satellite,and the like.

The encoded signals are then routed to an equalizer 825 for compensationof any frequency-dependent impairments that occur during transmissionthough the air such as phase and amplitude distortion. After equalizingthe bit stream, the modulator 827 combines the signal with a RF signalgenerated in the RF interface 829. The modulator 827 generates a sinewave by way of frequency or phase modulation. In order to prepare thesignal for transmission, an up-converter 831 combines the sine waveoutput from the modulator 827 with another sine wave generated by asynthesizer 833 to achieve the desired frequency of transmission. Thesignal is then sent through a PA 819 to increase the signal to anappropriate power level. In practical systems, the PA 819 acts as avariable gain amplifier whose gain is controlled by the DSP 805 frominformation received from a network base station. The signal is thenfiltered within the duplexer 821 and optionally sent to an antennacoupler 835 to match impedances to provide maximum power transfer.Finally, the signal is transmitted via antenna 817 to a local basestation. An automatic gain control (AGC) can be supplied to control thegain of the final stages of the receiver. The signals may be forwardedfrom there to a remote telephone which may be another cellulartelephone, other mobile phone or a land-line connected to a PublicSwitched Telephone Network (PSTN), or other telephony networks.

Voice signals transmitted to the mobile terminal 801 are received viaantenna 817 and immediately amplified by a low noise amplifier (LNA)837. A down-converter 839 lowers the carrier frequency while thedemodulator 841 strips away the RF leaving only a digital bit stream.The signal then goes through the equalizer 825 and is processed by theDSP 805. A Digital to Analog Converter (DAC) 843 converts the signal andthe resulting output is transmitted to the user through the speaker 845,all under control of a Main Control Unit (MCU) 803—which can beimplemented as a Central Processing Unit (CPU) (not shown).

The MCU 803 receives various signals including input signals from thekeyboard 847. The keyboard 847 and/or the MCU 803 in combination withother user input components (e.g., the microphone 811) comprise a userinterface circuitry for managing user input. The MCU 803 runs a userinterface software to facilitate user control of at least some functionsof the mobile terminal 801 to provide authentication session sharing.The MCU 803 also delivers a display command and a switch command to thedisplay 807 and to the speech output switching controller, respectively.Further, the MCU 803 exchanges information with the DSP 805 and canaccess an optionally incorporated SIM card 849 and a memory 851. Inaddition, the MCU 803 executes various control functions required of theterminal. The DSP 805 may, depending upon the implementation, performany of a variety of conventional digital processing functions on thevoice signals. Additionally, DSP 805 determines the background noiselevel of the local environment from the signals detected by microphone811 and sets the gain of microphone 811 to a level selected tocompensate for the natural tendency of the user of the mobile terminal801.

The CODEC 813 includes the ADC 823 and DAC 843. The memory 851 storesvarious data including call incoming tone data and is capable of storingother data including music data received via, e.g., the global Internet.The software module could reside in RAM memory, flash memory, registers,or any other form of writable storage medium known in the art. Thememory device 851 may be, but not limited to, a single memory, CD, DVD,ROM, RAM, EEPROM, optical storage, or any other non-volatile storagemedium capable of storing digital data.

An optionally incorporated SIM card 849 carries, for instance, importantinformation, such as the cellular phone number, the carrier supplyingservice, subscription details, and security information. The SIM card849 serves primarily to identify the mobile terminal 801 on a radionetwork. The card 849 also contains a memory for storing a personaltelephone number registry, text messages, and user specific mobileterminal settings.

While the invention has been described in connection with a number ofembodiments and implementations, the invention is not so limited butcovers various obvious modifications and equivalent arrangements, whichfall within the purview of the appended claims. Although features of theinvention are expressed in certain combinations among the claims, it iscontemplated that these features can be arranged in any combination andorder.

1. A method comprising: receiving, at an interface, an authenticationcontext associated with a first service; causing, at least in part,storage of the authentication context in a first cache associated withthe interface; and causing, at least in part, population of theauthentication context to a second cache associated with a secondservice, the second cache not directly linked to the interface, whereinthe authentication context in the second cache authenticates access tothe second service.
 2. A method of claim 1, wherein the population ofthe authentication context to the second cache comprises: converting theauthentication context based, at least in part, on an authenticationprotocol associated with the second service, wherein the authenticationcontext in the second cache is the converted authentication context. 3.A method of claim 1, further comprising: receiving, from the firstservice, a request to authenticate a user; requesting authenticationcredentials associated with the user; receiving the authenticationcredentials based on the request; causing, at least in part,transmission of the authentication credentials to an authenticationserver, wherein the authentication context is received from theauthentication server based, at least in part, on the authenticationcredentials.
 4. A method of claim 1, wherein the authentication contextis a single sign on authentication context applicable to both the firstservice and the second service.
 5. A method of claim 1, wherein thefirst service and the second service are runtime applications executingon a common device.
 6. A method of claim 1, wherein the first serviceand the second service include an application, a browser session.
 7. Anapparatus comprising: at least one processor; and at least one memoryincluding computer program code, the at least one memory and thecomputer program code configured to, with the at least one processor,cause the apparatus to perform at least the following, receive anauthentication context associated with a first service; cause, at leastin part, storage of the authentication context in a first cacheassociated with the apparatus; and cause, at least in part, populationof the authentication context to a second cache associated with a secondservice, the second cache not directly linked to the apparatus, whereinthe authentication context in the second cache authenticates access tothe second service.
 8. An apparatus of claim 7, wherein the populationof the authentication context to the second cache comprises: convertingthe authentication context based, at least in part, on an authenticationprotocol associated with the second service, wherein the authenticationcontext in the second cache is the converted authentication context. 9.An apparatus of claim 7, wherein the apparatus is further caused to:receive, from the first service, a request to authenticate a user;request authentication credentials associated with the user; receive theauthentication credentials based on the request; cause, at least inpart, transmission of the authentication credentials to anauthentication server, wherein the authentication context is receivedfrom the authentication server based, at least in part, on theauthentication credentials.
 10. An apparatus of claim 7, wherein theauthentication context is a single sign on authentication contextapplicable to both the first service and the second service.
 11. Anapparatus of claim 7, wherein the first service and the second serviceare runtime applications executing on a common device.
 12. An apparatusof claim 7, wherein the first service and the second service include anapplication, a browser session.
 13. An apparatus of claim 7, wherein theapparatus is a mobile phone further comprising: user interface circuitryand user interface software configured to facilitate user control of atleast some functions of the mobile phone through use of a display andconfigured to respond to user input; and a display and display circuitryconfigured to display at least a portion of a user interface of themobile phone, the display and display circuitry configured to facilitateuser control of at least some functions of the mobile phone.
 14. Acomputer-readable storage medium carrying one or more sequences of oneor more instructions which, when executed by one or more processors,cause an apparatus to at least perform the following steps: receiving anauthentication context associated with a first service; causing, atleast in part, storage of the authentication context in a first cacheassociated with the apparatus; and causing, at least in part, populationof the authentication context to a second cache associated with a secondservice, the second cache not directly linked to the apparatus, whereinthe authentication context in the second cache authenticates access tothe second service.
 15. A computer readable storage medium of claim 14,wherein the population of the authentication context to the second cachecomprises: converting the authentication context based, at least inpart, on an authentication protocol associated with the second service,wherein the authentication context in the second cache is the convertedauthentication context.
 16. A computer readable storage medium of claim14, wherein the apparatus is caused to further perform: receiving, fromthe first service, a request to authenticate a user; requestingauthentication credentials associated with the user; receiving theauthentication credentials based on the request; causing, at least inpart, transmission of the authentication credentials to anauthentication server, wherein the authentication context is receivedfrom the authentication server based, at least in part, on theauthentication credentials.
 17. A computer readable storage medium ofclaim 14, wherein the authentication context is a single sign onauthentication context applicable to both the first service and thesecond service.
 18. A computer readable storage medium of claim 14,wherein the first service and the second service are runtimeapplications executing on a common device.
 19. A computer readablestorage medium of claim 14, wherein the first service and the secondservice include an application, a browser session.